Capítulo 22 - Gestión de proyectos
Los proyectos necesitan administrarse porque la ingeniería de software profesional está sujeta siempre a restricciones organizacionales de presupuesto y fecha. El trabajo del administrador del proyecto es asegurarse de que el proyecto de software cumpla y supere tales restricciones, además de que entregue software de alta calidad.
La buena gestión no puede garantizar el éxito del proyecto. Sin embargo, la mala gestión, por lo general, da como resultado una falla del proyecto.
Metas importantes en un proyecto:
- Entregar el software al cliente en el tiempo acordado.
- Mantener costos dentro del presupuesto general.
- Entregar software que cumpla con las expectativas del cliente.
- Mantener un equipo de desarrollo óptimo y con buen funcionamiento.
Diferencias con la ingeniería tradicional
El producto es intangible
En un proyecto de ingeniería civil, si hay retraso en el calendario, es visible el efecto sobre el producto: es evidente que algunas partes de la estructura no están terminadas. El software es intangible. No se puede ver ni tocar. Los administradores de proyectos de software no pueden constatar el progreso con sólo observar el artefacto que se construye.
Los grandes proyectos de software con frecuencia son proyectos excepcionales
Los grandes proyectos de software se consideran en general diferentes en ciertas formas de los proyectos anteriores. Además, están los vertiginosos cambios tecnológicos en computadoras y comunicaciones. Las lecciones aprendidas de proyectos anteriores pueden no ser aplicables a nuevos proyectos.
Los procesos de software son variables y específicos de la organización
El proceso de ingeniería para algunos tipos de sistemas clásicos es bastante comprendido. Sin embargo, los procesos de software varían mucho de una organización a otra. No es posible predecir de manera confiable cuándo un proceso de software particular conducirá a problemas de desarrollo.
Actividades de los administradores de proyectos de software
Planeación del proyecto
Los administradores de proyecto son responsables de la planeación, estimación y calendarización del desarrollo del proyecto, así como de la asignación de tareas a las personas. Supervisan el trabajo para verificar que se realice de acuerdo con los estándares requeridos y monitorizan el avance para comprobar que el desarrollo esté a tiempo y dentro del presupuesto.
Informes
Los administradores de proyectos por lo común son responsables de informar del avance de un proyecto a los clientes y administradores de la compañía que desarrolla el software. Deben ser capaces de comunicarse en varios niveles, desde codificar información técnica detallada hasta elaborar resúmenes administrativos.
Gestión del riesgo
Los administradores de proyecto tienen que valorar los riesgos que pueden afectar un proyecto, monitorizar dichos riesgos y emprender acciones cuando surjan problemas.
Gestión de personal
Los administradores de proyecto son responsables de administrar un equipo de personas. Deben elegir a los integrantes de sus equipos y establecer formas de trabajar que conduzcan a desempeño efectivo del equipo.
Redactar propuestas
La primera etapa en un proyecto de software puede implicar escribir una propuesta para obtener un contrato de trabajo. La propuesta describe los objetivos del proyecto y cómo se realizará. La escritura de propuestas es una tarea esencial, pues la supervivencia de muchas compañías de software depende de contar con suficientes propuestas aceptadas y concesiones de contratos.
22.1 Gestión del riesgo
La gestión del riesgo implica anticipar riesgos que pudieran alterar el calendario del proyecto o la calidad del software a entregar, y posteriormente tomar acciones para evitar dichos riesgos. Podemos considerar un riesgo como algo que es preferible que no ocurra.
Los riesgos pueden amenazar el proyecto, el software que se desarrolla o a la organización.
Tres categorías:
- Riesgos del proyecto
Los riesgos que alteran el calendario o los recursos del proyecto. - Riesgos del producto
Los riesgos que afectan la calidad o el rendimiento del software a desarrollar. - Riesgos empresariales
Riesgos que afectan a la organización que desarrolla o adquiere el software.
Un ejemplo de riesgo de proyecto es la renuncia de un diseñador experimentado. Encontrar un diseñador de reemplazo con habilidades y experiencia adecuadas puede demorar mucho tiempo y, en consecuencia, el diseño del software tardará más tiempo en completarse.
Un ejemplo de riesgo de producto es la falla que presenta un componente que se adquirió al no desempeñarse como se esperaba. Esto puede afectar el rendimiento global del sistema, de modo que es más lento de lo previsto.
Un competidor que introduce un nuevo producto es un riesgo empresarial. La introducción de un producto competitivo puede significar que las suposiciones hechas sobre las ventas de los productos de software existentes sean excesivamente optimistas.
Las categorías de los riesgos pueden superponerse.
Análisis
Es necesario registrar los resultados del análisis del riesgo en el plan del proyecto, junto con un análisis de consecuencias, que establece las consecuencias del riesgo para el proyecto, el producto y la empresa.
Riesgos comunes
Los riesgos específicos que podrían afectar un proyecto dependen del proyecto y el entorno de la organización donde se desarrolla el software. Sin embargo, también existen riesgos comunes que no se relacionan con el tipo de software a desarrollar y que pueden ocurrir en cualquier proyecto.
Riesgo en proy. de software
Particularmente importante para los proyectos de software, debido a la incertidumbre inherente que enfrentan la mayoría de proyectos.
Ésta se deriva de requerimientos vagamente definidos, cambios de requerimientos que obedecen a cambios en las necesidades del cliente, dificultades en estimar el tiempo y los recursos requeridos para el desarrollo de software, o bien, se deriva de diferencias en las habilidades individuales.
Proceso de gestión del riesgo
- Identificación del riesgo: Hay que identificar posibles riesgos para el proyecto, el producto y la empresa.
- Análisis de riesgos: Se debe valorar la probabilidad y las consecuencias de dichos riesgos.
- Planeación del riesgo: Es indispensable elaborar planes para enfrentar el riesgo, evitarlo o minimizar sus efectos en el proyecto.
- Monitorización del riesgo: Hay que valorar regularmente el riesgo y los planes para atenuarlo, y revisarlos cuando se aprenda más sobre el riesgo.
Es preciso documentar los resultados del proceso de gestión del riesgo en un plan de gestión del riesgo.
El proceso de gestión del riesgo es un proceso iterativo que continúa a lo largo del proyecto.
22.1.1 Identificación del riesgo
Se ocupa de identificar los riesgos que pudieran plantear una mayor amenaza al proceso de ingeniería de software, al software a desarrollar, o a la organización que lo desarrolla.
La identificación del riesgo puede ser un proceso de equipo en el que este se reúne para pensar en posibles riesgos. O bien, el administrador del proyecto, con base en su experiencia, identifica los riesgos más probables o críticos.
Como punto de partida para la identificación del riesgo, se recomienda utilizar una lista de verificación de diferentes tipos de riesgo. Existen al menos seis tipos de riesgos que pueden incluirse en una lista de verificación:
- Riesgos tecnológicos: Se derivan de las tecnologías de software o hardware usadas para desarrollar el sistema.
- Riesgos personales: Se asocian con las personas en el equipo de desarrollo.
- Riesgos organizacionales: Se derivan del entorno organizacional donde se desarrolla el software.
- Riesgos de herramientas: Resultan de las herramientas de software y otro software de soporte que se usa para desarrollar el sistema.
- Riesgos de requerimientos: Proceden de cambios a los requerimientos del cliente y del proceso de gestionarlos.
- Riesgos de estimación: Surgen de las estimaciones administrativas de los recursos requeridos para construir el sistema.
Entonces se necesita reducir esta lista a un tamaño razonable. Si existen demasiados riesgos, será prácticamente imposible seguir la huella de todos ellos.
22.1.2 Análisis de riesgo
Durante el proceso de análisis de riesgos, hay que considerar cada riesgo identificado y realizar un juicio acerca de la probabilidad y gravedad de dicho riesgo. Usted debe apoyarse en su propio juicio y en la experiencia obtenida en los proyectos anteriores y los problemas que surgieron en ellos.
No es posible hacer valoraciones precisas y numéricas de la probabilidad y gravedad de cada riesgo. En vez de ello, habrá que asignar el riesgo a una de ciertas bandas:
- La probabilidad del riesgo puede valorarse como muy baja (< 10%), baja (del 10 al 25%), moderada (del 25 al 50%), alta (del 50 al 75%) o muy alta (> 75%).
- Los efectos del riesgo pueden estimarse como catastróficos (amenazan la supervivencia del proyecto), graves (causarían grandes demoras), tolerables (demoras dentro de la contingencia permitida) o insignificantes.
Luego hay que tabular los resultados de este proceso de análisis mediante una tabla clasificada de acuerdo con la gravedad del riesgo.
Para hacer esta valoración, se necesita información detallada del proyecto, el proceso, el equipo de desarrollo y la organización. Desde luego, tanto la probabilidad como la valoración de los efectos de un riesgo pueden cambiar conforme se disponga de más información acerca del riesgo y a medida que se implementen planes de gestión del riesgo.
Por lo tanto, esta tabla se debe actualizar durante cada iteración del proceso de riesgo.
Una vez analizados y clasificados los riesgos, valore cuáles son los más significativos. Su juicio debe depender de una combinación de la probabilidad de que el riesgo surja junto con los efectos de dicho riesgo.
El número correcto de riesgos a monitorizar debe depender del proyecto.
22.1.3 Planeación del riesgo
Considera cada uno de los riesgos clave identificados y desarrolla estrategias para manejarlos. Para cada uno de los riesgos, usted debe considerar las acciones que puede tomar para minimizar la perturbación del proyecto si se produce el problema identificado en el riesgo. También debe pensar en la información que tal vez necesite recopilar mientras observa el proyecto para que pueda anticipar los problemas.
Las estrategias se establecen en tres categorías:
- Estrategias de evitación: Seguir estas estrategias significa que se reducirá la probabilidad de que surja el riesgo.
- Estrategias de minimización: Seguir estas estrategias significa que se reducirá el efecto del riesgo.
- Planes de contingencia: Seguir estas estrategias significa que se está preparado para lo peor y se tiene una estrategia para hacer frente a ello.
Desde luego, es mejor usar una estrategia que evitar el riesgo. Si esto no es posible, se debe usar una estrategia que reduzca las posibilidades de que el riesgo cause graves efectos. Finalmente, se debe contar con estrategias para enfrentar el riesgo cuando éste surja. Tales estrategias deben reducir el efecto global de un riesgo en el proyecto o el producto.
22.1.4 Monitorización del riesgo
La monitorización del riesgo es el proceso para comprobar que no han cambiado sus suposiciones sobre riesgos del producto, el proceso y la empresa. Hay que valorar regularmente cada uno de los riesgos identificados para decidir si este riesgo se vuelve más o menos probable. También se tiene que considerar si los efectos del riesgo han cambiado o no. Los riesgos deben monitorizarse comúnmente en todas las etapas del proyecto.
Buenos indicadores a tener en cuenta:
22.2 Gestión de personal
Las personas que trabajan en una organización de software son los activos más importantes. Cuesta mucho dinero reclutar y retener al buen personal, así que depende de los administradores de software garantizar que la organización obtenga el mejor aprovechamiento posible por su inversión.
Cuatro factores críticos en la gestión de personal:
- Consistencia: todas las personas en un equipo de proyecto deben recibir un trato similar. Nadie espera que todas las distinciones sean idénticas, pero las personas podrían sentir que sus aportaciones a la organización se menosprecian.
- Respeto: las personas tienen distintas habilidades y los administradores deben respetar esas diferencias. Todos los miembros del equipo deben recibir una oportunidad para aportar.
- Inclusión: las personas contribuyen efectivamente cuando sienten que otros las escuchan y que sus propuestas se toman en cuenta.
- Honestidad: como administrador, siempre debe ser honesto acerca de lo que está bien y lo que está mal en el equipo.
La gestión de personal es algo que debe basarse en la experiencia, en lugar de aprenderse en un libro.
¿Por qué desarrollar el equipo?
- Mejorar el conocimiento y las habilidades de los miembros del equipo para aumentar su capacidad de completar los entregables a la vez que se disminuyen los costos, se reduce el cronograma y se mejora la calidad.
- Mejorar los sentimientos de confianza y cohesión entre los miembros del equipo a fin de elevar la moral, disminuir los conflictos y fomentar el trabajo en equipo.
- Crear un cultura de equipo dinámico y cohesivo.
22.2.1 Motivación del personal
Como administrador de proyecto, usted necesitará motivar a las personas con quienes trabaja, de manera que éstas contribuyan con lo mejor de sus habilidades.
Motivación significa organizar el trabajo y el ambiente laboral para alentar a los individuos a desempeñarse tan efectivamente como sea posible.
Si las personas no están motivadas, no estarán interesadas en la actividad que realizan. Así que trabajarán con lentitud, y será más probable que cometan errores.
Jerarquía de Maslow
Sugiere que las personas se sienten motivadas para cubrir sus necesidades, las cuales se ordenan en una serie de niveles.
Los niveles más bajos de esta jerarquía representan necesidades fundamentales de alimentación, sueño, etcétera, y la necesidad de sentirse seguro en un ambiente.
Las necesidades sociales se relacionan con el hecho de sentirse parte de un grupo social. Las necesidades de estima representan la necesidad de sentirse respetado por otros, y las necesidades de autorrealización tienen que ver con el desarrollo personal.
Las personas que trabajan en organizaciones de desarrollo de software, por lo general, no están hambrientas ni sedientas ni físicamente amenazadas por su ambiente.
Asegurarse de que se cubren las necesidades sociales, de estima y autorrealización de las personas es más importante desde un punto de vista administrativo.
Bass y Dunteman: tipo de personalidad
Clasifican a los profesionales en tres tipos:
- Personas orientadas a las tareas, quienes están motivadas por el trabajo que realizan. En la ingeniería de software se trata de personas que están motivadas por el reto intelectual de desarrollar software.
- Personas orientadas hacia sí mismas, quienes están motivadas principalmente por el éxito y el reconocimiento personales. Están interesadas en el desarrollo del software como un medio para lograr sus propias metas. Esto no significa que esos individuos sean egoístas y sólo piensen en sus propios intereses. En vez de ello, suelen tener metas a plazos más largos, como el avance profesional; de esta manera, se sienten motivados a tener éxito en su trabajo para conseguir dichas metas.
- Personas orientadas a la interacción, quienes están motivadas por la presencia y las acciones de los compañeros de trabajo. Conforme el desarrollo de software se vuelve más centrado en el usuario, los individuos orientados a la interacción se involucran más en la ingeniería de software.
Teoría de los factores de higiene de Herzberg
Factores de higiene:
- Pueden destruir la motivación, pero mejorarlos (en la mayoría de los casos) no mejorará la motivación.
- Algunos ejemplos de factores de higiene son: Condiciones de trabajo, Salario, Vida personal, Relaciones en el trabajo, Seguridad.
Teoría X e Y de McGregor
Dos supuestos opuestos que hacen los gerentes en cuanto a la naturaleza humana.
22.3 Trabajo en equipo
Grupo cohesivo: una unidad, motivados por el éxito del equipo y no el personal.
¿Cuáles son los beneficios de tener un equipo cohesivo?
- Estándares propios
- Aprendizaje compartido
- Compartir conocimiento
- Mejora continua
¿Qué factores afectan un equipo?
- Miembros del equipo
- Balance entre habilidades técnicas y personalidades
- Balance de personalidades
- Organización
- ¿El PM debe ser el líder técnico? ¿Quién toma decisiones críticas técnicas? ¿Quién interactúa con quién? ¿Cómo manejar co-locación?
- Comunicaciones
Comunicación
La cantidad de posibles canales de comunicación en un equipo de proyecto está dada por la fórmula
Habilidades importantes:
- Hacer preguntas
- Parafrasear
- Resumir
- Hacer contacto visual
- Comprender la real intención del mensaje
- Escucha activa
5 etapas del desarrollo de un equipo
Según Tuckman & Jensen, 1977
- Un equipo puede estancarse en una de las etapas o retroceder
- En equipos que ya trabajan juntos se puede saltear alguna de las etapas
- La duración de una etapa depende del tamaño y liderazgo del equipo
- 5 etapas:
- Formación
- Turbulencia
- Normalización
- Desempeño
- Disolución
Formación
Esta es la fase en que se reúne el equipo y se informa acerca del proyecto y de cuáles son sus roles y responsabilidades formales. En esta fase, los miembros del equipo tienden a actuar de manera independiente y no demasiado abierta.
Turbulencia
Durante esta fase, el equipo comienza a abordar el trabajo del proyecto, las decisiones técnicas y el enfoque de dirección del proyecto. Si los miembros del equipo no colaboran ni se muestran abiertos a ideas y perspectivas diferentes, el ambiente puede tornarse contraproducente.
Normalización
En la fase de normalización, los miembros del equipo comienzan a trabajar conjuntamente y a ajustar sus hábitos y comportamientos para apoyar al equipo. Los miembros del equipo comienzan a confiar unos en otros.
Desempeño
Los equipos que alcanzan la etapa de desempeño funcionan como una unidad bien organizada. Son interdependientes y afrontan los problemas con eficacia y sin complicaciones.
Disolución
En la fase de disolución, el equipo completa el trabajo y se desliga del proyecto. Esto sucede normalmente cuando se libera al personal del proyecto, al estar completos los entregables o como parte de la ejecución del proceso Cerrar el Proyecto.
Gestión de conflictos
Los conflictos son naturales e inevitables
Algunas fuentes:
- Cronograma
- Choques personalidad
- Costos
- Opiniones técnicas, etc
Una actitud de apertura ayuda a resolverlos, su resolución debe centrarse en el problema, no en las personas y a la vez centrarse en el presente y no en el pasado.
Técnicas para la gestión de conflictos
- Retirarse/Eludir. Retirarse de situaciones de conflicto reales o potenciales. Es una táctica de retraso que “enfría” la situación.
- Suavizar/Adaptarse. Suavizar las diferencias y resaltar los puntos en común. No resuelve el problema pero mantiene un ambiente cordial.
- Consensuar/Conciliar. Buscar soluciones que aporten un cierto grado de satisfacción a todas las partes.
- Forzar/Dirigir. Imponer su propio punto de vista. Una de las partes gana y la otra pierde.
- Colaborar/Resolver el problema. Incorporar múltiples puntos de vista y visiones desde diferentes perspectivas; requiere una actitud colaboradora y un diálogo abierto que normalmente conduce al consenso y al compromiso.
Desarrollo ágil
SW entregado en incrementos .
No se hace un plan exhaustivo, se va decidiendo según el avance y las prioridades del cliente.
Manifiesto ágil 2001:
- Individuos e interacciones sobre proceso y herramientas.
- SW funcionando sobre documentación extensiva.
- Colaboración con el cliente sobre negociación contractual.
- Respuesta ante el cambio sobre seguir el plan.
- Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor
- Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
- Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiables la ejecución del trabajo.
- Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
SCRUM
Un marco de trabajo mediante el cual las personas pueden hacer frente a problemas adaptativos complejos, mientras entregan, creativa y productivamente, productos del mayor valor posible.
--La guía Scrum - Julio 2013--
5 valores:
- Foco: en conjunto acotado de funcionalidades por vez.
- Coraje: apoyo como equipo para afrontar desafíos.
- Apertura: transparencia y discusión abierta.
- Compromiso: equipos comprometidos
- Respeto: respeto mutuo y ayuda
3 pilares
- Transparencia
- Inspección
- Adaptación
MVP (Minimum Viable Product)
Es la versión mínima de un producto tal que nos permite recolectar la mayor cantidad de información de nuestro mercado con el menor esfuerzo.
Haciendo foco en características mínimas y necesarias para que el producto pueda lanzarse
Release plan
Plan de sprints de acuerdo a la velocidad del equipo.
Considerando prioridades.
